Blogs

You may have seen already the new Toolkit from AIIM titled “Document Imaging in SharePoint”.  If you haven’t, then as soon as you finish this post you know where to go.  I’m not just excited about this toolkit because of its topic; I’m excited because I’m the author.  You may take that as pure bragging rights, but as soon as you have gone through the process of writing such a toolkit you will understand.

So yes this post is a little bit of an ad, and teaser for the new toolkit.  But mostly it’s a 50,000 foot view of document imaging in SharePoint.  The toolkit itself is pretty dense, so I want to point out at a high level what document imaging in SharePoint entails.

As you know, the vast majority of the ECM solutions out there have a capture component.  Whether developed in-house or acquired through acquisition, the ECM companies know that paper is a great way to start populating a content management system.  Although Microsoft did not go out and create a capture component, performing capture with SharePoint essentially involves all the same considerations and steps.

One trendy fallacy that comes with the ECM solutions that have boxed capture is the assumption that the capture component “must be the best for this system”.  This is often not true.  Many times it’s better to, instead of using boxed Capture, go out and find the best capture for the job and then integrate it.  The very root of this perception is why document imaging in SharePoint has not seen the growth that it should.  The fallacy  is that already established “connectors” or “exports” or “links” whatever you want to call them, are the most important thing to consider when picking capture.  This is a huge mistake.

When looking at capture, it’s always best to find the best capture product for the job, and then worry about the connection to the ECM system after.  Because all systems support some level of standards, the connectivity between two systems is trivial compared to the complexity involved in a good capture product.  And I promise you; even if there is a magic “connector” it’s going to require some work.

This is where the opportunity of imaging in SharePoint lies.  Pick the best capture product, setup SharePoint appropriately (see the toolkit of course), and start scanning.  Most of the capture products out there have releases to SharePoint.  The typical release will allow you to scan imagines to a document library.  The more advanced releases will allow you to store images and meta-data, and some even automatically create folders.  The real power, however, is in two killer new features in SharePoint 2010 that make document imaging all the more charming.  And they are:

1. Content organizer:  A capture environment can now be configured to scan to a single library known as the “Drop off Library”.  Based on pre-established rules that document and meta-data will be automatically moved to the appropriate library without the scanning operator having to think about it.  This is not only for standard document imaging, it also serves as a place to house exceptions and build exception handling processes around images that are not routed.  But wait  there’s  more!  You can also automatically kick off workflows, and using destination settings make documents inherit meta-data.
2. Document Sets:  True compound documents that allow you to map the document structure at scan time to other resulting multiple, multi-page documents that are saved in SharePoint.

So the best capture product for an environment with even the most limited SharePoint integration is going to be a great solution now with SharePoint 2010. When picking Capture, an organization only needs to consider its capture requirements versus what product seems to “connect” the best to its ECM system.  Because you have no choice but to go with a third party capture solution, there are some additional considerations you should make when looking at capture with SharePoint.

1. Quotas.  Understand how and when you will start segmenting images into new folders, document sets, libraries, sites, and even site collections.  This includes considerations for the new feature in SharePoint 2010 called the Remote Blob Storage (RBS), Compression, etc.
2. Capture template mapping to Content Types.  Most capture products have some variation of what is called a “Template”.  A list of fields and possibly coordinates and business logic to capture those fields.  When document imaging in SharePoint, consideration must be given to mapping those capture templates with content types inside of SharePoint, as well as the change control and management of them.
3. Security.  Consider how scan agents will authenticate with SharePoint, and how you will track when, where, and who created documents.
4. Search.  Making sure that the meta-data and content of the scanned documents is available for search.

These plus more are covered in the toolkit and augmented with the other fabulous Chris authored “OCR Checklist”. I’m hoping that the combination of the ROI associated with document imaging and the adoption rate of SharePoint will break down the walls of document imaging apprehension.  As they do,  it will be more and more important that organizations take full responsibility of how they plan for the solution, evaluate potential products, and ultimately choose a document capture solution.